Computing systems typically allow various applications to access hardware devices installed on or otherwise associated with the computing system. Such devices include, by way of example only, storage devices, cameras, microphones, printers, location service devices, video capture devices, and the like. While having such hardware devices available allows applications to provide functionality that is desired by users, controlling access to such devices by different applications can be problematic. For instance, it is possible for an application to access potentially risky capabilities without the user's consent or knowledge. For example, there are existing exploits that target location services, messaging services, and the like that can compromise a user's privacy or cause the user to be charged by their network provider without the user's knowledge or consent. While users may be prompted for their approval in order for an application to access a particular device or device capability, such prompting can be difficult to explain to users. For example, when prompting a user for approval, it can be difficult to explain to the user exactly what access to a particular device or device capability is requested by an application and what the implications of allowing the access are. This can result in a confusing user experience.
Further, where supported, users may add new hardware devices to their existing computer configuration, for instance, peripheral hardware devices. The addition of these new devices complicates traditional approaches for allowing applications to access hardware devices and/or device capabilities because it is oftentimes assumed that the list of known possible hardware devices and their capabilities is always available. Further, existing approaches to adding peripheral hardware devices using ubiquitous protocols (e.g., USB, HID, Bluetooth, Bluetooth LE, etc.) generally require custom drivers making them prohibitively costly to support.